	Here are some important things to be aware of regarding this JSON.

=== Proper Use of the Party "type" ===

The JSON defined here makes use of a common element "type" called Party, which consists
of the following fields:

	- handle
	- domain
	- networkHandle
	- networkDomain
	- networkDisplay

This "type" then defines various fields with names like transferringParty, eventingParty,
calledParty, etc.

This type has been defined for a very specific purpose -- to represent the leg of a call
or conference in such a way that the handle and domain uniquely identify the leg of the
call in a nonmutable way for the life of the call or conference. In contrast, the
"network" prefixed fields hold the current identity of the leg and may change over time.

For a call intercept scenario, an "offered" event is generated to indicate that an
"invite" to start a call has been received and "continued". The event contains a
callingParty and a calledParty. The callingParty handle/domain is the original handle and
domain of the person or device that "invited" someone else (Alice in an "Alice calling
Bob" scenario). Similarly, the calledParty handle/domain is the handle and domain of the
person or device that is targeted when the call is "continued" (in this "Alice calling
Bob" scenario, Bob, if the call is allowed, and Bob-prime, if the call is "diverted to").
In later phases of the call, after the call is set up as a two-party call where neither
leg has been dropped, the eventingParty handle/domain in an event will match those of
either the callingParty or the calledParty from the offered event; this is different
from the situation in the Call family, where the handle and domain of an eventingParty
might have changed, based on new "identities being asserted" on a call leg.

For a callable service scenario, things are a bit different. Traditionally, for a callable
service the callingParty handle/domain comes from those of the calling party, and the
calledParty handle/domain comes from the handle and domain configured for the callable
service. However, the definition of Party used here prevents the Party "type" from being
used to represent the callable service. In a callable service, there is only one leg in a
call. Therefore, the Party definition of handle/domain precludes the use of Party "type"
for the callable service, since the callable service is not a leg of the call. This means
that the "offered" event used to indicate that a service has been called can only have one
field with a "type" of Party. That field is callingParty. Information about the callable
service handle and domain is made available through a callableService field.

=== The Unusual Way that the JSON for Party is Defined Here ===

As discussed above, the JSON defined here makes use of a common element "type" called
Party. It is desirable here to define the JSON in a way so that, when the JSON is
converted into Java classes, a class named "Party" is created and used as the type for
transferringParty, eventingParty, calledParty, etc.

Unfortunately, the code generation plugin in use here -- jsonschema2pojo-maven-plugin --
makes it very difficult to achieve this. JSON does make it possible in various ways to
define a "Party" JSON "object" with the above fields as components, where this object can
be referenced from multiple places using "$ref". However, attempts to force the code
generator to define a Java class called Party that is used as the type in the generated
code for the fields transferringParty, eventingParty, calledParty, etc. is very difficult.
Instead, when the code generator runs, it will take the name of the first field it
encounters that does a "$ref" of "Party" and create a class named the same as that first
field. So instead of ending up with a set of fields like transferringParty, eventingParty,
calledParty, etc. all of type Party, one ends up with something like transferringParty,
eventingParty, calledParty, etc. all of type TransferringParty. It appears the code
generator goes through the JSON by first ordering the files alphabetically and then going
top to bottom through each file.

To get the desired behavior, a trick has been used. The party "type" has been defined in
the "definitions" section of the file Aa01Party.json. The "Aa01" prefix ensures that the
file is processed first by the code generator. Then, a field called "party" within the
Aa01Party.json file explicitly does a "$ref" of party in the definitions section. The
result is a Java file/class called Party.java. This class then gets used as the type for
the transferringParty, eventingParty, calledParty, etc. fields in the other Java files.
One unfortunate but benign side effect is that an Aa01Party.java file also gets generated
that never gets used.

An attempt was made to find a JSON code generating alternative to jsonschema2pojo-maven-
plugin that could be run in Maven, but there were no obvious good alternatives, and
jsonschema2pojo-maven-plugin appears to be the plugin commonly used by Java developers.
